NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/17123

Internet Message Format | 1996-08-05 | 6.1 KB

Path: prairienet.org!wemccaug
From: [e-mail] (Wendy E. McCaughrin)
Newsgroups: comp.lang.c++
Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
Date: 13 Apr 1996 23:25:37 GMT
Organization: University of Illinois at Urbana
Message-ID: <4kpd5h$[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Wendy E. McCaughrin)
NNTP-Posting-Host: firefly.prairienet.org


In a previous article, [e-mail] (Piercarlo Grandi) says:

>>>> On Tue, 2 Apr 1996 15:47:22 GMT, [e-mail] (David L. Shang)
>>>> said:
>
>shang> In article <[e-mail]> [e-mail]
>shang> (Piercarlo Grandi) writes:
>
>pcg> Therefore exception handling reduces to simply providing a mechanism by
>pcg> which the *author* of a code segment provides a mechanism by which the
>pcg> *user* of that code segment can specify additional cases, as for example

sjm> No. 'exception handling' is a mechanism to provide handlers for
     exceptions, written by other authors, not the poor end-user.
     Besides, if they could add more cases of exceptions, this im-
     plies the code isn't finished yet -- is this interpretive code?

>pcg> in:
>
>pcg> float sqrt(float n)
>pcg> {
>pcg>   if
>pcg>     n > 0 -> ...;
>pcg>     [] n == 0 -> return 0;
>pcg>     [] n < 0 -> return sqrt_negative(n);
>pcg>   fi
>pcg> }
>
>pcg> where the only difficulty is that sqrt_negative must be dynamically
>pcg> scoped instead of statically scoped, for it must be redefinable by
>pcg> the *user* of the procedure.

sjm> Dijkstra's guarded-command language finally made it to comp.lang!
     So here must be where you are referring to addition of a new case
     to test (n < 0) and then providing your handler for it -- so in
     fact, the code was completed but not compiled: would that we all
     had such easy access to the source.
>
>pcg> This again means that termination is the only possible outcome for
>pcg> this case too.

 sjm> How so? You returned, didn't you? Let's get clear on this
      "termination vs. resumption" semantics: it only means you
      branch instead of call, i.e., you pass control to some
      handling mechanism with no provision for return.

>
>shang> Termination? When you execute:
>
>shang>     return sqrt_negative(n)
>
>shang> first, you call "sqrt_negative" to get the result, then you do
>shang> return to terminate. It is not the case that you first terminate
>shang> then you call "sqrt_negative".shang> go back.
>
>This is just a low level, mechanical view of
>exceptions/termination/resumption, as indeed demonstrated by your
>subsequent example, which is nothing but an assembler-like expansion of
>what I had written above:

 sjm> "...just a low level, mechanical view...": aren't you confusing
      interrupt-handling with exception-handling?
>
>shang> Once your terminate, you can never If I write code like:
>
>shang>      float sqrt(float n)
>shang>      {
>shang>        if
>shang>           n > 0 -> ...;
>shang>        [] n == 0 -> return 0;
>shang>        [] n < 0 -> { n1= sqrt_negative(n); return n1; }
>shang>        fi
>shang>      }
>
>shang> Is the program terminated
>
>Why should one terminate the _program_? Exception handling's purpose is
>precisely not to terminate the program, but to allow it to continue,
>even if on a different path.

 sjm> I would in part agree, but a fuller statement of purpose would be:
      "exception handling's purpose is to avoid the unpleasantness of
      abnormal termination whenever possible, but otherwise to exit
      gracefully with a fully descriptive diagnostic for termination".

>
>When we are talking of termination/continuation semantics, we are
>talking about the termination/continuation of the bit of code that had
>the problem, not that of the program (or even that of the containing
>scope, I would say).
>
>shang> at the point of calling "sqrt_negative"?  This embedded exception
>shang> handler exactly provides a resumption semantics,
>
>Not at all: for the 'if-fi' is not resumed/continued in any way.
>
>Actually if you agree, as you logically must, that an "exception" is a
>misnomer for the case where a partial function is applied to a value
>outside its codomain, then talking about "exception handlers" and
>termination and continuation does not mean much: the only thing that
>matter is that the partial function is not continued, and that another
>bit of code is used.
>
>The advocates of continuation semantics think that it makes sense
>because they imagine it is possible to make the exception handler wiggle
>things so that the current state of the computation is changed to one
>that *is* in codomain of the ``failing'' partial function; for example
>if on reading one gets EOF on the current volume, the exception handler
>can mount another volume, and on resumption the EOF is gone and
>everything is OK.
>
>But I'd regard this a terrible use of "exception handling", for there is
>no need to use the machinery of dynamic binding in this case, because
>what happens on EOF is not something that cannot be designed in at the
>time the rest of the code is written; in fact essentially all the uses
>of continuation sematics amount to using exception handling instead of a
>'case' or an 'if' with more branches.
>
>shang> which, according to your previous analysis, is the only case that
>shang> exception handling makes any sense(?).
>
>Perhaps we are using "termination" in a different sense: to me in a
>semantic sense, where the current computation simply cannot progress
>because it is a partial function applied to a value outside its
>codomain. If a partial function is applied outside its codomain, then it
>simply *cannot* be continued/resumed/...
>
>You are instead perhaps thinking of non-local control transfers, as in:
>termination semantics for exceptions *necessarily* involve a non local
>control transfer.
>
>To me the issue of exception handling and non local control transfers
>are totally unrelated and independent; not necessarily an exception
>handler shall 'longjmp'/'throw'/... outside the current function. What
>in any case *must* happen is that the current computation is not
>continued, for it cannot continue.
>